How to Unblock Engineers and Boost Engineering Productivity

This post is part of our historical archive. It represents the beliefs, actions, products, and services of Code Climate as of its publication date. Today, Code Climate focuses on providing enterprise leaders the software development data, context layer, and playbooks needed to build the AI-native software organization their enterprise needs. Head to codeclimate.com to learn more.

One of the first and most essential uses of Velocity is to cut through the noise and help managers identify the signals of stuck engineers. This enables management to eliminate unnecessary check-ins, while still having the ability to unblock engineers and boost engineering productivity by stepping in to help an engineer who might hesitate to raise their hand.

Dec 23, 2020 • 4 min read

Velocity provides visibility into:

• Who on your team is blocked
• Whose work has been churning

Look out for four main behavioral patterns in Velocity to help address these concerns.

Engineers Who Haven’t Committed for a Long Time

A quick scan of the Activity tab will help you identify developers who aren’t checking in code.

Head into the Team360 report, select the Activity tab, and look for team members with few or no commits, represented as purple circles.

In the example above, Hecate hasn’t committed in a couple of days. This could indicate that she is:

• Working on a large chunk of work locally
• Stuck for whatever reason
• Tied up in non-engineering related projects

If you see a similar work pattern in your team’s Activity Log, you might want to check in to identify the bottleneck and help your developer get back on track.

Engineers Who Are Committing but Churning

Any developers who are committing, but not opening PRs, might be churning. Once again, go to the Activity tab in the Team360 report to see which engineers’ work appears to be blocked.

As noted in the key, Commits and Merged Commits are indicated by dark and light purple circles respectively and open PRs by light blue diamonds. You’ll want to look out for clusters with a high count of circles and a missing count of diamonds.

As you can see in the top row, Donalbain has been consistently committing code, but not opening any PRs.
This could be because he is:

• Committing a lot then planning to open one big PR (which isn’t ideal)
• Committing something, then redoing the work he just did for some reason
• Committing something, then heading off in a different direction and starting a new track of work

Take this opportunity to dive in and identify the issue.

Engineers Who Have Long-running PRs

Long-running PRs may indicate that an engineer is stuck on that particular unit of work, or that they’re multi-tasking, causing delays for multiple PRs.

Investigate all open and active PRs in the Pull Requests report. (Note that if you look at this report in the morning, it might look bare, since it automatically shows “today’s” activity. In this case, use the date picker to extend to yesterday, or the past two days to see what’s in progress).

To surface the oldest PRs, sort by age by clicking on the “AGE” header. Pay close attention to anything that’s been open for over 72 hours.

A PR might be long-running because:

• An engineer is having trouble with this PR and keeps adding on commits.
• It’s unclear whether this PR is done.
• An engineer’s PR hasn’t been picked up for review, either because it was overlooked or because it’s perceived as complex.
• An engineer is blocked on another third party.

Engineers Whose Work is Stuck in the Review Process

Finally, the Analytics tab is a good place to go to identify late-stage churn. You’ll want to run a query for Review Cycles, or the number of times a Pull Request has gone back and forth between the author and reviewer.

To obtain this report, select Review Cycles as your metric, and group by contributor. Run a query for the last week or two, and scroll to the bottom until you see the following bar graph visualization:

When Review Cycles are high, it may indicate:

• There are differing opinions about what “done” means.
• There’s misalignment around what kind of changes are expected to come out of the review process.
• There are conflicting ideas about how a solution should be implemented.

Boost Your Own Engineering Productivity with Data

With the right data, you can identify which of your team members are stuck right now, so you can help remove the roadblock and get things moving again.

If you want to boost engineering productivity, but don’t have a way to track and analyze your engineering metrics, reach out to find out more about our Software Engineering Intelligence platform, Velocity.