When code review is laborious and takes hours or days, developers avoid working in small batches and instead batch up many changes. This in turn leads to a downward spiral where reviewers procrastinate with large code reviews due to their complexity. - DORA DevOps Research
Delays to your code review process can slow down your team's velocity and negatively impact the team's engagement.
But what causes a slow code review process?
Here are the top five issues I have encountered in more than ten years of leading Software Engineering teams and provide an easy way to spot them:
1. Approver bottlenecks
Some companies only allow technical leaders or a limited set of people to review. They become bottlenecks from time to time.
How to spot it: A person has too many pending pull requests on their plate.
2. Large batch or story size
People can't review several weeks or months of work in a contiguous work slot of a couple of hours. Reviewers will have to switch back and forth with other activities, amplifying the delay.
How to spot it: Developer working in a case/ticket for more than two weeks.
3. The review criteria are not known upfront
Unless they know what the reviewers are looking for, people will repeatedly send PRs until they are approved.
How to spot it: Most PRs are rejected on their first review.
4. Fear or approving
It may paralyze some reviewers from approving a PR if they think it is their responsibility to stop a bad change.
How to spot it: The reviewer takes too much time to review changes in general.
5. Too many things to review
If your PRs have too many things to review, you might be imposing too much work on the reviewers.
How to spot it: The review checklist has many items. Small changes require considerable review time.
Follow me on Twitter for more articles on leading software engineering teams. I publish twice a week.
