Are Your Remote Teams Productive? Use These 3 Key Metrics To Find Out

As a leader, do you find yourself wondering just how productive your newly remote teams are? Now that offices are empty and everyone is meeting by Zoom, feeling nervous about team productivity would be natural. By collecting just 3 key metrics you can get a handle on team productivity.

These insights are based on a recent study of 50 teams conducted by development company LinearB. LinearB looked at the performance of 50 different teams and they were able to compare data from just prior to the shift to remote working to the month following it. The findings are enlightening and they could be a really good proxy for what is happening with your own teams.

Remote Teams Had Less Agility

The headline is that remote teams on the whole are less productive and less agile. This may come as no surprise that the measures showed the remote teams to have less agility than when they were co-located. You are probably experiencing this yourself.

One client complained to me that now that everyone is remote, everyone gets included in all meetings. At another client, daily agile team meetings grew to include more than 20 people as more and more people wanted to sit in to know what was going on. The meetings grew so unwieldy that they added a daily “pre-meeting” to prepare for the daily meeting!

And that leads to another complaint from this client and I suspect from many others. Everyone is fatigued. While it may seem like working remotely would be easier and require less hours per day (e.g. less time commuting, fewer interruptions), people are finding themselves exhausted. Anecdotally it seems to be because there is a blurring of home and work life and of course, the deluge of Zoom meetings. People are Zoomed out.

Anecdotes aside, let’s take a look at the actual data from LinearB and see what that tells us about the teams.

What LinearB Found about Remote Team Productivity

Here are three specific findings from the LinearB studies:

1. Remote Teams had Higher Cycle Times

Overall cycle time for development went up. Cycle time is measured as the time between when the team begins work on a particular backlog item and when it is ready for customer deployment.

LinearB had statistics on each stage of development as shown below. Overall cycle time had grown by 46%. Things were just taking longer. Digging in they found that:

• Coding time has increased 47%
• Review time has increased 71%
• Release time has increased 58%

By itself, an increase in coding time was not worrisome. After the shift to remote working, individuals had more time to focus on coding (92% of the teams in the study reported that they were writing more code). What was worrisome was the time it took for code reviews and releases.

2. More Maintenance and Less Investment in New Development

A second key finding is that there was a small but noticeable shift in investment from innovation or new development to maintaining old code. Whereas prior to the shift to remote working teams were averaging 61% innovation or new development and 39% maintenance, after going remote the amount of innovation decreased to 54%.

LinearB did not have an explanation for this shift but I wonder if it relates to the difficulty people have in being creative when they are afraid. It could be that the new innovative work is just not possible when our amygdala is hijacked. So perhaps people are shifting to easier bug fixing and maintenance work and avoiding deep thinking.

3. Releases are Bigger and Less Frequent

The data showed a third concerning trend related to releases. As noted above, release time had increased by 58%. The size of the releases increased by 64% and the number of releases decreased by 21%.

They believe this is because the remote teams tended to delay releases. Coupled with the fact that each individual developer was writing more code, this means that releases are getting bigger.

Bigger releases run counter to the agile principles. Traditionally, teams had large releases which were painful and risky. As a result, they tended to do them less frequently and this became a vicious cycle.

The third agile principle says to “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” Frequent, small deliveries result in shorter feedback loops and lower risk.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

— Principles Behind the Agile Manifesto

5 Action Steps You Can Take Now to Help Your Remote Teams

Some of you may have the luxury of great tooling like LinearB from which you have data to support decision-making at your fingertips. Congratulations, that is awesome! For others, well, it will not be that simple.

#1 – Collect Data About Your Teams Development Processes

One thing to be learned from LinearB is the importance of good data about your process. Management guru Peter Drucker said, “you can’t manage what you can’t measure.” So while the LinearB data is a good indicator of what is likely happening to your teams, it would be more effective to have your own data.

At a minimum, you should be measuring and have a baseline for these three things: Cycle Time, Release Size (and Release Frequency), and Investment Profile. (See this related article from the Engineering leader at LinearB). Don’t have these measures right now? Well, as they say, the best time to start collecting this data was a year ago and the next best time is now.

Don’t be fooled into thinking that your current crisis and short-term demands are more important than data right now. Or that there will be some magical future date when you will have the time to implement metrics that you don’t have now. You won’t. Make time for it now.

#2 – Share Data and Discuss

While having good data is a great start, the data needs to be shared with teams and with business partners, and IT leadership. Use it in discussions with Leadership, Product Management, and Development Teams. Where possible it should be tied to business goals. If our cycle time is going up, how does that affect our plans for the upcoming product release?

Do you believe that executives are not interested in the data about your process? This related LinerB article describes two key data points that technical leaders should be sharing with the CEO and other business leaders each week.

#3 – Encourage Team Collaboration beyond the Daily Standup

While the positive side of remote working was more individual productivity, teamwork and collaboration clearly suffered. It seems that for many, the queues and handoffs were increasing. Code reviews became less frequent and bigger, and the delays between a developer coding and a second developer reviewing were bigger. This points to people working in their own silos and not focusing on collaboration.

You’ve probably experienced this yourself. Working remotely provides less opportunities for casual discussions or interactions. Individual team members tend to become more isolated and work more heads down.

The antidote is to raise awareness of this tendency and counter it with more frequent collaboration. Recognize that working remotely can increase handoffs and delays if not addressed in a conscious way. Some teams use Slack or always on video. Leverage paired programming and mob programming to increase the amount of team collaboration and discourage individuals from working in silos.

#4 – Keep Backlog Items Small

Though not specifically called out in the LinearB study, there is often a direct relationship between the size of backlog items and cycle time and release size. To counter longer cycle times, encourage teams to make backlog items smaller.

More frequent backlog refinement sessions may be needed. It may also help to have a definition of ready.

#5 – Automate, Automate, Automate

Some people equate automation with DevOps tooling like MS Azure. Sure those tools can help but simply installing a tool is rarely a fix and often introduces new problems.

All steps in the process are candidates for automation. Peer code reviews should be automated. All the data you need to produce the metrics above should be automated. Certainly, tooling is required for continuous integration / continuous deployment.

I you don’t have a solid process and haven’t invested in tools, this is going to inhibit your agility. Like metrics, this is often considered a low priority while current short-term problems occupy leaders and teams. If there is one clear lesson from being suddenly remote it is that we cannot focus solely on the short term.

Learn More About Leading Remote Teams:

Interested in learning more about leading remote teams? Here are a few articles that may be helpful to you:

• What is the Role of the Agile Leader – We explain the role of the agile leader in transformation.
• LinearB Overview Article from DZone – This article provides an overview of the key findings of the study.
• Download the LinearB 17-Page Study (Registration Required)