Review code faster

Going faster helps the team

Pull requests stick around for many reasons. Some are just too big, or the reviewer isn’t familiar with the context or the codebase. Sometimes reviewing and merging is thwarted by poor planning or lack of infrastructure, and often it’s just a case of poor visibility into review requests. Bottlenecks abound for pull requests, one of the most common being the code review.

Reviewing code quickly as a team comes with multiple benefits. Developers expand their comfort zone, the codebase becomes more robust, there’s a more frequent sense of accomplishment, and new features can be shipped faster. No matter the reasons for stuck pull requests, reviewing code without delay is always a good idea, and it’s always a challenge you must address as a team.

By managing the amount of work in progress and code review time, teams can significantly accelerate their pull request cycle times. After getting into the habit of quick code reviews, teams can expect to close 80% of pull requests within 48 hours, and rarely have to deal with pull requests older than 14 days.

Check the current situation

Lack of visibility is a common cause for stuck pull requests. Swarmia's Pull Request view gives a quick overview of what’s going on, and the charts give an idea of team throughput and bottlenecks. Getting in the habit of checking the Pull Request view from time to time goes a long way to ensuring that pull requests are moving.

The above Pull Request view tells you a lot about your situation. A large number of pull requests in progress is often a sign of a problem, and being able to see pull request ages helps you to understand its magnitude. The graphs above your pull request inbox give insights about cycle time and pull request throughput trends over time.

💁‍♀️ Visit the Pull Request view regularly. It’s usually enough to check how many pull requests are open, and that there are no old and stale pull requests sitting on the shelf. Think of it as a canary in the goldmine, it's worth a closer look if there are apparent issues.

It’s normal that pull requests sometimes sit for a day or two before merging, but if many of your pull requests are weeks old, it’s time to dive deeper.

Investigate throughput and trends

Before jumping into Swarmia’s Working Agreements to set throughput targets for your team, it’s worth the time to investigate past performance and estimate sustainable levels of throughput going forward.

Flow Insights is a good way to take a look at the pull request conundrum over a longer period. By reviewing past work in progress and cycle times, you can spot trends and begin to estimate realistic targets for future throughput. Importantly, pull request review time is often a reliable leading indicator of total cycle time.

In the above example, it looks like median review and cycle time are quite healthy, but there are plenty of outliers with high review times and cycle times. According to the Review Times scatter plot, a handful of pull requests have been waiting for review for quite some time, and while there are lots of pull requests assigned to other teams for review, they seem to be done quickly and are not the bottleneck. So, it looks like there are issues with code review that are worth addressing as a team!

💁‍♀️ Help stakeholders understand. Improving code review time requires the team to invest some extra time and effort. Most businesspeople love the idea of going faster, so backed with data it shouldn’t be too hard to get them onboard.

Based on your team’s throughput over time, come up with an ambitious but realistic goal for pull request review time. Can you think of any reason why code reviews should take longer than three working days to complete? Talk it over with the team and stakeholders, and make sure to explain that reviewing code faster is a big step towards delivering features faster.

Zero in on code review

For most teams we see, code review is the bottleneck where progress stalls and throughput falters, making pull request review time a reliable leading indicator of total cycle time. Improving your team’s code review practices will go a long way towards speeding up pull request cycle times and improving team dynamics as a whole.

💁‍♀️ Start with code review. Working Agreements about pull requests help teams get their pull request game on point and improve throughput. Code review time is usually a leading indicator of total pull request cycle time, so focus on that first.

To get started with improving your code review time, head over to Working Agreements and adopt a new agreement to review pull requests within a few working days, according to the analysis you’ve just made.

After configuring and adopting the new working agreement, outliers become clearly visible in context, exceptions from the past two weeks are spelled out, and the scatter plot highlights delays caused by cross-team collaboration.

In your next retrospective, review the list of exceptions together as a team. What made these pull requests so special? Getting in the habit of analyzing exceptions in retrospectives is all but guaranteed to regularly surface actionable insights about your process and lead to real improvements.

💁‍♀️ Review exceptions in retrospectives. Regularly going through recent exceptions to working agreements with your team is a great way to uncover insights about what’s holding you back and to systematically improve your review habits.

Increase visibility

While it’s important to analyze the reasons behind stuck pull requests in retrospect for systemic improvement, identifying and addressing problems right away can have an immediate impact on cycle times. Swarmia’s Slack notifications help your team preempt delays by increasing the team’s visibility into review requests, and detect problems as soon as they occur.

💁‍♀️ Remember to talk with the team. Don’t forget to talk with your team and agree that this is a problem you are committed to solving before setting up Slack notifications. Regular broadcasts about pull requests and other work in progress can feel more disruptive than useful if they start arriving on the team’s channel suddenly and without explanation.

Encouraging team members to connect their personal Slack accounts, as well as connecting your team’s Slack channel in Swarmia, are great ways to increase visibility into review requests. When a review is requested from the team or an individual, Swarmia sends a notification either to the team’s channel or as a direct message.

To avoid redundant notifications, the original message is simply struck through after the review is completed and the pull request is merged.

💁‍♀️ Take full advantage of GitHub. To ensure that review requests don’t fall through the cracks, set up code owners for your repositories. Use GitHub’s draft pull request feature to clearly identify work in progress where actual code review is not yet called for.

Despite increased visibility, delays in reviews are bound to happen. To catch problems as they occur, set up the daily Slack digest for your team to understand what’s in progress and which pull requests need attention, and get timely feedback about working agreements that are slipping.

Exceptions in the Slack digest are your cue to revisit the Pull Request view, check which pull requests are problematic and have a short conversation as a team about what’s actually going on. Often getting unstuck is as simple as properly assigning the task or asking a quick question!

Next steps

When it looks like you’re consistently hitting your code review targets, it’s a good idea to dive deeper into the pull request cycle time, and explore issues of focus and work in progress. We recommend arranging a team discussion about limiting the amount of pull requests in progress at a given time, for which there is its own Working Agreement, as well as setting targets for pull request cycle time as a whole.

As you go on, the conversations you will have with your team about exceptions will help you surface all manner of improvements and spur you along on the path of continuous improvement. Good luck!