Mike Koeneke

To deliver innovative products and experiences, engineering teams must work efficiently without compromising quality. Over the years, the software development lifecycle (SDLC) has evolved to include code reviews to ensure this balance. But, as engineering teams grow, so can the complexity of the review process. From understanding industry benchmarks to improving alignment across teams, this article outlines strategies that large engineering organizations can use to optimize Review Cycles.

Understanding Pull Request Review Cycles

The Review Cycles metric measures the number of times a Pull Request (PR) goes back and forth between an author and a reviewer. The PR review process is an essential component of PR Cycle Time, which measures the time from when the first commit in a PR is authored to when it’s merged. Leaders use this data to understand how long it takes to deliver innovation and establish baseline productivity for engineering teams.

Consider a PR for a new feature. Before the PR gets merged, it must be reviewed by a member of the team. If the PR gets approved and merged in a single cycle with no further interaction from the author, then the Review Cycle count is one. If the PR is not approved and requires changes, then the author must make an additional commit. The reviewer then checks the new version before it’s approved. In this scenario, the number of Review Cycles is two. This number increases as the PR is passed back and forth between the author and the reviewer.

By evaluating engineering metrics across enterprise companies, Code Climate identified a pattern in high-performing teams. Research found that the top 25% of organizations have an average of 1.1 Review Cycles, whereas the industry average is 1.2 cycles. When Review Cycles surpass 1.5, it’s time to investigate why.

What Causes a High Number of Review Cycle?

A high number of Review Cycles in engineering might stem from a combination of challenges that hinder the efficiency of the process. These include differing interpretations of what constitutes "done," misalignment between the expected changes and the actual changes resulting from the review, or conflicting views on the best approach to implement a solution. If there are anomalies where Review Cycles are high for a particular submitter, it could indicate they’re struggling with the codebase or aren’t clear about the requirements. This presents an opportunity for leadership to provide individualized coaching to help the submitter improve the quality of their code.

The first step in addressing a high number of Review Cycles is to identify the reason PRs are being passed back and forth, which requires both quantitative and qualitative information. By looking at Review Cycles alongside other PR metrics, leaders can look for correlations. For example, Review Cycles tend to be high when PR Size is high. If this is true in your organization, it might be necessary to re-emphasize coding best practices and encourage keeping PRs small.

Leaders might also want to do a closer review of PR data to understand which PRs have the highest Review Cycles. They can bring this information to the teams working on those PRs to uncover what exactly is causing the PRs to bounce around in review. Maybe there’s a misalignment that can be worked through, or requirements are shifting while the project is in progress. Leaders can work with teams to find solutions to limit the number of times PRs are volleyed back and forth by establishing expectations for reviews, how solutions should be implemented, and when a review is complete. Best practices for the PR review process should be documented and referenced by all team members.

Optimizing Pull Request Reviews to Meet Business Goals

For large engineering organizations, paying attention to Review Cycles is essential. Keeping Review Cycles low can boost efficiency, productivity, and innovation by minimizing delays and facilitating swift project progression. In addition, when Review Cycles are high, it can be a signal of a bigger issue that needs to be addressed, like a misalignment within a team, or a failure to maintain best practices.

Standups should be a vital ceremony for building trust and cohesion within a team. They’re meant to help your team remain engaged and adaptable, so they can keep work moving forward.

The reality is, most standups do none of that.

It’s not that standups aren’t a good idea in theory; teams should have a regular touchpoint that enhances collaboration and alignment. In practice, however, they fall flat. Too often, standups are held simply because they’re expected — they’re a cornerstone of agile, after all — not because they provide value to the team. They’re frequently maligned as boring and ineffective.

Like all processes that exist because of a shared understanding of how things “should” be, standups are in need of an overhaul.

To add value back into your standups, focus on the reason you’re holding them in the first place. Foreground those goals (alignment, adaptability, and engagement), and think about the particular dynamics of your team. How can you encourage your team members to contribute in a meaningful way, and to help fulfill the goals of the standup?

Every team is different, which means every answer will be slightly different. You’ll likely have to iterate before you land on a process that works for your team. And you’ll have to continue to iterate as your team and its needs change.

That said, there are a few broad strategies we here at Code Climate recommend:

Keep key questions at the forefront – Once you’ve decided on the critical questions that every standup needs to answer, make sure that information stays top of mind for all involved. We recommend pasting these questions into the standup calendar invite and revisiting them at the beginning of every standup, so they serve as a constant reminder to attendees and help keep conversations focused. The key questions we ask are:

• What did you work on yesterday?
• What are you working on today?
• Are you blocked on anything?

Don’t be afraid to ask follow up questions too, as long as they help further the goals for your meeting.

Prepare with data – To be impactful, standups need to surface the units of work most in need of attention and discussion. While you should create an environment that will encourage your team members to speak up when they need help, it’s not a guarantee that they will. A Software Engineering Intelligence (SEI) platform like Code Climate can help you spot bottlenecks and identify at-risk work, so you can walk into standups prepared. If your team members raise those issues, you’ll be ready to offer guidance. If they don’t, you can raise them yourself and help troubleshoot so that the sprint stays on track.

Create a blameless space – Ensure your team members understand that they won’t be penalized for raising an issue or voicing a concern. This will help create a feeling of safety — when engineers know they won’t be punished for it, they’ll be more likely to surface potential problems and ask for help.

Leave time for hesitation – Before moving on to the next person or topic, leave a moment of pause. Sometimes there’s an impulse to move through standup as fast as possible for efficiency’s sake. It may sound counterintuitive, but when you’re trying to keep standups efficient and impactful, moments of pause are key. If an IC is considering voicing a concern, but hesitating, you want to create an opportunity for them to speak up — often those moments of hesitation give rise to the most important conversations.

Embrace fast follow ups –  Block off 20 minutes of time after every standup for follow-up conversations. If something comes up during standup that requires further conversation, you’ll have a block of time to have that conversation with the relevant teammates while things are still fresh in your head. You won’t need to derail standup for a deep dive that doesn’t impact the rest of your team, but you won’t delay the conversation for too long either.

With these strategies, you’ll be on your way to running more effective, impactful standups. Your team will start the day of strong, poised to tackle their most challenging work and keep code moving through the development pipeline.

To find out more about using data to prepare for your standups, request a consultation.